home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000033_icon-group-sender _Wed Sep 16 12:36:10 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA02192
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 16 Sep 1998 12:36:09 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA05198; Wed, 16 Sep 1998 12:35:41 -0700
  7. Date: Wed, 16 Sep 1998 09:42:26 -0700
  8. From: swampler@noao.edu (Steve Wampler)
  9. Subject: Re: Context Switching
  10. To: icon-group@optima.CS.Arizona.EDU
  11. Message-Id: <swampler-9808161642.AA000619813@orpheus.gemini.edu>
  12. In-Reply-To: <35FF1A94.66F1@gte.net>
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15.  
  16. MJE wrote:
  17. > If you want a language that can do a lot more than C, then why rely all
  18. > the time on C conventions, instead of making your own?
  19.  
  20. Performance and effort.
  21.  
  22. > Icon is wonderful with strings because the strings are not C strings,
  23. > they are Icon objects.  Analogy:  Icon can be wonderful with stacks,
  24. > because the stacks are not C stacks, but Icon stacks.
  25.  
  26. True, but most hardware has pretty direct support of C-style stacks,
  27. unless you design very carefully, it's easy to lose performance when
  28. you adopt other approaches.
  29.  
  30. > Icon has complete control of how it handles functions, coexpressions,
  31. > recursion, and so on, there is no mandatory requirement that they all be
  32. > treated as C function calls.  Icon doesn't have to put parameters on a
  33. > stack, it can put them on the heap and "context-switch" by switching
  34. > data pointers to blocks on the heap.  You could implement several
  35. > "stack" structures right on the heap, instead of relying on the system
  36. > stack.
  37.  
  38. Unless thinks have changed a lot since co-expressions were originally
  39. implemented, this is already exactly how Icon implements co-expressions -
  40. multiple heap-based stacks.  This is also why you see co-expression
  41. stack overflow related errors - heap-based stacks are difficult to
  42. implement w/o the hardware support given to the system stack.  As an
  43. historical aside, the original co-expression implementation did not
  44. have this problem, but only because of hardware support for user stacks
  45. on the PDP-11 class machines - highly non-portable.
  46.  
  47. > Those heap-based stacks would handle all the issues involved in
  48. > context-switching, without resorting to fancy thread systems.
  49.  
  50. Agreed, but for the most part, heap-based stacks are (were?) how
  51. co-expressions are implemented - to get the rest of the functionality
  52. you (and most of the rest of us) would like is a *major* rewrite of
  53. the implementation, see below.
  54.  
  55. > Built-in operators and functions can easily be rewritten to assume that
  56. > their stack exists elsewhere.  I.e., as C calls, they take no input
  57. > parameters, but instead lookup a global pointer that gives them their
  58. > current stack somewhere on the heap, then they take parameters from
  59. > that.
  60.  
  61. Well, you shouldn't think in terms of a stack at this point, you
  62. have a general call graph now - each context (function, etc.) would
  63. have a node in the call graph for each invocation instance.  Using
  64. heap based stacks is what Icon has now, but usually implemented to
  65. be efficient by using C-style stack access conventions.
  66.  
  67. The 'functionally correct' way to implement Icon would be to go to
  68. what could be called an object-based implementation - each context
  69. would exist as an object in the heap.  It is very hard to implement
  70. this efficiently, however, and the original implementation represented a
  71. trade between portability and efficiency.
  72.  
  73. > Or, rather than rewriting the builtins, you just wrap them with
  74. > "handlers" that know about these things and put the right parameters
  75. > into the standard C function calls.  So, none of the built-ins change,
  76. > but you add "handlers" to baby-sit them with respect to the switching
  77. > stacks.
  78. > 
  79. > The idea of "fooling" the Icon executable, and doing so in a way that is
  80. > non-portable, assembler-based, and buggy, and that will break with every
  81. > vendor's compiler release, is what I dislike.
  82. > 
  83. > I just wanted to share these ideas.  Maybe I haven't really knocked down
  84. > your points, but that's OK, we share ideas here.
  85.  
  86. A *long* ago I thought about an object-based implementation for co-expressions
  87. (more precisely for *all* context switching in Icon (a function call is also
  88. a context switch)) - since that's really what is needed for this approach to
  89. work).  Mark is correct, it can be made to work, but it isn't easy to
  90. implement both correctly and efficiently.
  91.  
  92. Personally, I would enjoy seeing such an implementation of Icon - it
  93. would be an interesting experiment to watch.   It would not be a trivial
  94. undertaking and I suspect the Icon-project has enough to do already, so
  95. someone else would probably have to take the initiative.
  96.  
  97. --
  98. Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
  99. The gods that smiled at your birth are now laughing openly. (Fortune Cookie)
  100.